Use HTML Tag Processor to audit blocking scripts & styles in Site Health’s enqueued-assets test #2059

b1ink0 · 2025-06-18T19:27:02Z

Summary

Fixes #2030

Relevant technical choices

This PR overhauls the Site Health "Enqueued Scripts" and "Enqueued Styles" tests to accurately detect and report only truly render-blocking scripts and styles, whether loaded from external files or defined inline. It achieves this by performing an unauthenticated loopback request and analyzing the resulting front-end HTML with the WP_HTML_Tag_Processor.

…d styles

…ed-assets

… inline script sizes in the asset audit

b1ink0 · 2025-06-18T19:44:17Z

plugins/performance-lab/includes/site-health/audit-enqueued-assets/hooks.php

+			$path = perflab_aea_get_path_from_resource_url( $href );
+			if ( '' === $path ) {
+				continue;
+			}


Currently, our audit only scans assets located in the WordPress content directory. This raises an question,
how should the audit treat scripts and styles served from a CDN? Should these third-party resources be included in the render-blocking report, excluded entirely, or perhaps flagged separately so we can distinguish external blocking assets from local ones?

I think we’ll also need to consider how to measure their sizes efficiently. One approach could be, sending an HTTP HEAD request to the CDN-hosted URL to check for a Content‑Length header.

cc: @westonruter

From a performance perspective, CDN-served assets could be even worse for performance since they require a new TCP connection, now that browsers don't reuse cached resources across origins. So we definitely should be including them in the render-blocking report.

Sending an HTTP HEAD request for all resources regardless of whether they are on the same origin or not makes sense to me. If the request returns in a 404 then this would be important to report as well.

Once we have the report, then a future enhancement would be digging in to find the theme/plugin responsible for the resource being added in the first place. The AMP plugin implements a lot of this, and it was getting extracted a separate package via https://github.com/GoogleChromeLabs/wp-origination but that effort got stalled and was abandoned. See also #1095.

Should we consider a case where a HEAD request does not return a content length due to server configuration? If so, should we then make a GET request?

Perhaps, but that might be overkill.

OK, sounds good. In that case, let's not do the HEAD request at all and only do GET. The assets should all be relatively small (a few hundred KB at maximum), so it shouldn't be a problem to just go ahead and download them to check the byte size of the body.

Done in aa50fe4.

Sending an HTTP HEAD request for all resources regardless of whether they are on the same origin or not makes sense to me. If the request returns in a 404 then this would be important to report as well.

Now that the GET request is sent, should only 404 errors be added to the report, or should any errors that occur during the request be added to the report?

Once we have the report, then a future enhancement would be digging in to find the theme/plugin responsible for the resource being added in the first place. The AMP plugin implements a lot of this, and it was getting extracted a separate package via https://github.com/GoogleChromeLabs/wp-origination but that effort got stalled and was abandoned. See also #1095.

So does it make sense to add a table in the blocking scripts/styles site health test showing the origin of each blocking asset, or should this be part of Optimization Detective as you mentioned in #1095?

cc: @westonruter

I think this is related to #2059 (comment).

I think instead of just saying whether the sum of of the bytes for blocking assets is above a given threshold, that it would be better to list out the assets in a table with a sum at the end. It wouldn't necessarily be able to identify the theme/plugin responsible for adding the script or stylesheet, but in cases where the script/style is bundled with the theme/plugin then this would be obvious.

b1ink0 · 2025-06-18T19:47:31Z

plugins/performance-lab/includes/site-health/audit-enqueued-assets/hooks.php

+			if ( ! is_string( $href ) || false !== strpos( $href, 'wp-includes' ) ) {
+				continue;
+			}


We currently skip any URL containing wp-includes (i.e. core assets). Since the goal is to surface all render-blocking resources, should we remove that exclusion and include core scripts and styles in the audit as well?

I think this exclusion should be removed, yes.

b1ink0 · 2025-06-18T19:51:07Z

plugins/performance-lab/includes/site-health/audit-enqueued-assets/hooks.php

+			// Process blocking inline scripts.
+			if ( ! is_string( $src ) ) {
+				$script_size = mb_strlen( $processor->get_modifiable_text(), '8bit' );
+				if ( false !== $script_size ) {
+					$assets['scripts'][] = array(
+						'src'  => 'inline',
+						'size' => $script_size,


Currently each inline SCRIPT is reported as its own entry, do we want to continue treating every inline script separately, or would it make sense to aggregate inline scripts into a single summary?

I don't think inline scripts need to be counted since the render blocking is not significant compared to blocking external scripts.

codecov · 2025-06-20T08:11:49Z

Codecov Report

Attention: Patch coverage is 54.23729% with 108 lines in your changes missing coverage. Please review.

Project coverage is 66.33%. Comparing base (ff5cc68) to head (e44ee9f).
Report is 75 commits behind head on trunk.

Files with missing lines	Patch %	Lines
...ludes/site-health/audit-enqueued-assets/helper.php	33.54%	107 Missing ⚠️
...cludes/site-health/audit-enqueued-assets/hooks.php	98.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##            trunk    #2059      +/-   ##
==========================================
- Coverage   68.03%   66.33%   -1.71%     
==========================================
  Files          92       93       +1     
  Lines        7631     7863     +232     
==========================================
+ Hits         5192     5216      +24     
- Misses       2439     2647     +208

Flag	Coverage Δ
multisite	`66.33% <54.23%> (-1.71%)`	⬇️
single	`36.00% <47.45%> (-1.02%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

plugins/performance-lab/includes/site-health/audit-enqueued-assets/helper.php

plugins/performance-lab/includes/site-health/audit-enqueued-assets/hooks.php

westonruter · 2025-06-25T18:55:36Z

plugins/performance-lab/includes/site-health/audit-enqueued-assets/hooks.php

+	if (
+		! is_admin() ||
+		! current_user_can( 'view_site_health_checks' ) ||
+		( false !== get_transient( 'aea_enqueued_front_page_scripts' ) && false !== get_transient( 'aea_enqueued_front_page_styles' ) )


I think it would make sense to combine these two transients into one aea_blocking_assets, or something like that

…rt HEAD request

Co-authored-by: Weston Ruter <[email protected]>

…page loads Co-authored-by: Weston Ruter <[email protected]>

…assets` transient Co-authored-by: Weston Ruter <[email protected]>

westonruter · 2025-06-26T18:59:31Z

plugins/performance-lab/includes/site-health/audit-enqueued-assets/helper.php

+	if ( false !== strpos( $resource_url, '?' ) ) {
+		$resource_url = substr( $resource_url, 0, strpos( $resource_url, '?' ) );
+	}


Suggested change

if ( false !== strpos( $resource_url, '?' ) ) {

$resource_url = substr( $resource_url, 0, strpos( $resource_url, '?' ) );

}

$resource_url = preg_replace( '/\?.*/', '', $resource_url );

Nevertheless, the perflab_aea_get_path_from_resource_url() function isn't being used now anymore, right?

Yes its not being used anymore I just put comment about it here #2059 (comment).

plugins/performance-lab/includes/site-health/audit-enqueued-assets/helper.php

Co-authored-by: Weston Ruter <[email protected]>

…s are now resolved via HEAD requests

…urement

…ction

github-actions · 2025-07-02T21:14:39Z

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: b1ink0 <[email protected]>
Co-authored-by: westonruter <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

plugins/performance-lab/includes/site-health/audit-enqueued-assets/helper.php

westonruter · 2025-07-02T22:59:41Z

plugins/performance-lab/includes/site-health/audit-enqueued-assets/helper.php

+	$body = wp_remote_retrieve_body( $response );
+	if ( '' === $body ) {
+		return null;


Could it be that the body length is actually zero in this case?

I’m not understanding what you’re trying to suggest. If you’re referring to cases when an asset has no content and the server returns an empty string, this will ignore such assets. Should these assets still be included in the asset count?

Yes, but the issue is that a zero-size body would still be a blocking request.

So I think this condition should be removed.

Done in 0be6561.

plugins/performance-lab/includes/site-health/audit-enqueued-assets/helper.php

Co-authored-by: Weston Ruter <[email protected]>

westonruter

Sorry for the delay in reviewing.

westonruter · 2025-07-05T22:24:39Z

plugins/performance-lab/includes/site-health/audit-enqueued-assets/helper.php

-	if ( 0 === strpos( $resource_url, content_url() ) ) {
-		return WP_CONTENT_DIR . substr( $resource_url, strlen( content_url() ) );
+	if ( is_wp_error( $response ) || 200 !== wp_remote_retrieve_response_code( $response ) ) {
+		return null;


What if instead of returning null here, it instead returns the WP_Error instance if that's what $response is, or else to return a new WP_Error if the response code is not 200. This could be displayed in the UI then, instead of silently ignoring it. If there is a script on the page that is pointing to a 404, then this would be very important to capture since (1) it would still be a potentially blocking request, (2) a 404 would probably be served by WP which would be relatively very slow compared to serving a static asset.

For this, does it make sense to show a table of failed requests with some info about them, or a general list saying there is an issue with the following assets?

Yes, in fact I think it would be good to have a table listing out each blocking asset, including whether it is a script or stylesheet, the URL of the asset, and the size. When there is an error obtaining the asset, this can be indicated in the table for that row.

Done in 6b23854.

Any suggestions on UI @westonruter ?

plugins/performance-lab/includes/site-health/audit-enqueued-assets/helper.php

westonruter · 2025-07-05T22:25:51Z

plugins/performance-lab/includes/site-health/audit-enqueued-assets/hooks.php

-				continue;
-			}
+	if ( is_wp_error( $response ) || 200 !== wp_remote_retrieve_response_code( $response ) ) {
+		return;


A failure here should result in some message in the Site Health test, no?

I have added a new Site Health test in a77ab19, which will be triggered when the response is a WP_Error, the response code is not equal to 200, or the body is empty.

I think adding this new test and omitting the other tests is better, as it does not make sense to show two failed tests with the similar messages.

WP_Error:

Response code is not equal to 200:

Response code is 200 but body is empty:

Why would this be a new test and not just a unique status for the existing test?

There are two tests: one for styles and one for scripts. When the request to the home page fails, both of these tests will be omitted in the previous logic. There are two ways to display the error: one is to show the message on one of the existing tests, and the other is to show it in a different, new test. In my opinion, the second seems correct. I am open to any new suggestions for other approaches.

Oh, I think the two test styles and scripts can be combined into one asset test, and the failure will be one of the cases in it.

Ah, OK. Yes, what you have makes sense.

Another option would be for there to be just one test for both scripts and styles. This test would be for the "blocking assets" rather than two separate tests for "blocking scripts" and "blocking styles". I don't feel strongly either way.

Okay, combining them would work.

Done in 93e30ac.

westonruter · 2025-07-05T22:26:27Z

plugins/performance-lab/includes/site-health/audit-enqueued-assets/hooks.php

-			}
+	$html = wp_remote_retrieve_body( $response );
+	if ( '' === $html ) {
+		return;


Ditto. If the HTML response is empty, then this here would indicate a problem with the test that could be exposed.

See #2059 (comment).

plugins/performance-lab/includes/site-health/audit-enqueued-assets/hooks.php

Co-authored-by: Weston Ruter <[email protected]>

…s site health test

…rmation

b1ink0 added 6 commits June 6, 2025 00:07

Refactor to use HTML Tag Processor for processing enqueued scripts an…

Verified

This commit was signed with the committer’s verified signature.

davep Dave Pearson

GPG key ID: B413E0EF113D4ABF

Verified
Learn about vigilant mode

1e60c9a

…d styles

Merge branch 'trunk' into fix/inaccurate-site-health-tests-for-enqueu…

8baf9af

…ed-assets

Refactor to use single loop to extract enqueued assets

0f4b4ba

Add support to skip async/defer/module/non-JS scripts and include all…

4a37fff

… inline script sizes in the asset audit

Add support for processing inline styles in enqueued assets audit

8e5b9dc

Rename enqueued assets site health tests to blocking assets

Loading
Loading status checks…

d53ad9b

b1ink0 added this to the performance-lab n.e.x.t milestone Jun 18, 2025

b1ink0 requested a review from westonruter June 18, 2025 19:27

b1ink0 added [Type] Bug [Plugin] Performance Lab labels Jun 18, 2025

b1ink0 commented Jun 18, 2025

View reviewed changes

b1ink0 added 2 commits June 19, 2025 23:39

Add method to mock loopback request for tests

3bdae33

Fix failing tests caused by using loopback requests for asset auditing

Loading
Loading status checks…

2846222

b1ink0 added 3 commits June 24, 2025 10:58

Remove exclusion of core assets

Loading
Loading status checks…

668808a

Exclude inline assets from audit

Loading
Loading status checks…

40377b8

Add remote HEAD–based asset sizing for blocking assets site health test

Loading
Loading status checks…

092ef31

westonruter reviewed Jun 25, 2025

View reviewed changes

plugins/performance-lab/includes/site-health/audit-enqueued-assets/helper.php Outdated Show resolved Hide resolved

westonruter reviewed Jun 25, 2025

View reviewed changes

plugins/performance-lab/includes/site-health/audit-enqueued-assets/hooks.php Outdated Show resolved Hide resolved

westonruter reviewed Jun 25, 2025

View reviewed changes

plugins/performance-lab/includes/site-health/audit-enqueued-assets/hooks.php Outdated Show resolved Hide resolved

westonruter reviewed Jun 25, 2025

View reviewed changes

plugins/performance-lab/includes/site-health/audit-enqueued-assets/hooks.php Outdated Show resolved Hide resolved

westonruter reviewed Jun 25, 2025

View reviewed changes

b1ink0 and others added 4 commits June 26, 2025 15:26

Fix failing tests by refactoring HTTP request mocking method to suppo…

Loading
Loading status checks…

84692cf

…rt HEAD request

Improve type safety by using nullable return type

Loading
Loading status checks…

f341208

Co-authored-by: Weston Ruter <[email protected]>

Ensure transients are always set to avoid repeated auditing on admin …

Loading
Loading status checks…

12d1cc7

…page loads Co-authored-by: Weston Ruter <[email protected]>

Consolidated script and style transients into a single `aea_blocking_…

Loading
Loading status checks…

e58e451

…assets` transient Co-authored-by: Weston Ruter <[email protected]>

westonruter reviewed Jun 26, 2025

View reviewed changes

plugins/performance-lab/includes/site-health/audit-enqueued-assets/helper.php Outdated Show resolved Hide resolved

b1ink0 and others added 10 commits June 27, 2025 00:58

Simplify conditional checks

Loading
Loading status checks…

f83151b

Co-authored-by: Weston Ruter <[email protected]>

Improve script type validation to match core behavior

Loading
Loading status checks…

fc7a9a2

Remove perflab_aea_get_path_from_resource_url() as local asset path…

Loading
Loading status checks…

80e08ef

…s are now resolved via HEAD requests

Forward basic auth headers when available

b19371c

Replace HEAD request with GET to measure actual asset size in bytes

6e27de3

Update tests to mock GET requests instead of HEAD for asset size meas…

Loading
Loading status checks…

aa50fe4

…urement

Skip non-blocking stylesheets with media attribute hack

Loading
Loading status checks…

f582186

Improve test code coverage for blocking assets audit function

Loading
Loading status checks…

9b917c3

Add tests to improve test code coverage for blocking assets audit fun…

Loading
Loading status checks…

9bbedb3

…ction

Add tests to improve test code coverage for helper functions

Loading
Loading status checks…

e45f459

b1ink0 marked this pull request as ready for review July 2, 2025 21:14

b1ink0 requested review from manuelRod, mukeshpanchal27 and felixarntz as code owners July 2, 2025 21:14

b1ink0 requested a review from westonruter July 2, 2025 21:14

westonruter reviewed Jul 2, 2025

View reviewed changes

b1ink0 and others added 4 commits July 3, 2025 19:52

Simplify blocking assets validation conditions

Loading
Loading status checks…

31fafb7

Co-authored-by: Weston Ruter <[email protected]>

Remove redundant HTTP_AUTHORIZATION check for basic auth headers

Loading
Loading status checks…

2878c74

Co-authored-by: Weston Ruter <[email protected]>

Fix failing tests

Loading
Loading status checks…

76716c9

Remove redundant empty body check in asset size calculation

Loading
Loading status checks…

0be6561

Co-authored-by: Weston Ruter <[email protected]>

westonruter reviewed Jul 5, 2025

View reviewed changes

b1ink0 and others added 5 commits July 7, 2025 14:06

Simplify condition checks for improved readability and consistency

Loading
Loading status checks…

c314d49

Co-authored-by: Weston Ruter <[email protected]>

Improve regex to handle leading whitespace

Loading
Loading status checks…

7d2b544

Co-authored-by: Weston Ruter <[email protected]>

Remove redundant type casting

Loading
Loading status checks…

d405d06

Add Site Health test for blocking assets retrieval failures

Loading
Loading status checks…

a77ab19

Combine separate scripts and styles tests into unified blocking asset…

Loading
Loading status checks…

93e30ac

…s site health test

westonruter mentioned this pull request Jul 9, 2025

Proposal: Just-In-Time Block CSS #2076

Open

b1ink0 added 2 commits July 10, 2025 15:04

Add a table for blocking assets site health test to display more info…

Loading
Loading status checks…

6b23854

…rmation

Update asset size test to assert WP_Error for HTTP errors

Loading
Loading status checks…

e44ee9f

Use HTML Tag Processor to audit blocking scripts & styles in Site Health’s enqueued-assets test #2059

Are you sure you want to change the base?

Use HTML Tag Processor to audit blocking scripts & styles in Site Health’s enqueued-assets test #2059

Conversation

b1ink0 commented Jun 18, 2025

Summary

Relevant technical choices

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

b1ink0 Jul 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

codecov bot commented Jun 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

github-actions bot commented Jul 2, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

westonruter Jul 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

b1ink0 Jul 4, 2025 •

edited

Loading

codecov bot commented Jun 20, 2025 •

edited

Loading

westonruter Jul 3, 2025 •

edited

Loading